obhavefandomcom-20200213-history
OBHave Content Item
OBHave Content Item is a wrapper object for the REST API Resources. OBHave will track the properties of REST API Resources (RAR) in order to utilize unsupervised learning (and in some cases supervised learning) to generate Rules, which are used for Reinforcement Learning of other components. Front-end will decide how CI is rendered like in any other application based on REST, OBHave will choose which RAR will be queried for in specific situations. CI events will always be Rewards with above zero value. For each component that interacts with CIs, stress is caused by the amount of interactions before the desired goal is reached. For example, if CI is extended with Rating capability, it is weighted so that average rating equals 1. Because rating is one interaction event and the total Reward is the sum of all rewards divided by interaction count, we get following situations: * The user only consumes a CI, the Machine will be rewarded 1 point * The average rating is 4 out of 5, the user consumes the CI and rates it with 2, which give total reward of 1 from consumption, 0.5 (2 divided by 4) from the rating and the sum of 1.5 is divided by 2 (the interaction count), which gives total reward of 0.75. * The average rating is 2.5 out of 5, the user consumes the CI and rates it with 5, which give total reward of 1 from consumption, 2 (5 divided by 2.5) from the rating and the sum of 3 is divided by 2 (the interaction count), which gives total reward of 1.5 Depending on the use case, we could also give penalty from below average rating, even though it could make unsupervised learning more complicated. Giving it a negative value might feel intuitive, but in the end, having a user consume a content and give negative feedback could be a positive goal. Especially when we have Rules! A rule could state that it follows CIs with rating above 3 out of 5 and it could increase in weight if user groups has a good consensus about ratings. Another rule could follow CIs with ratings of 2 and below out of 5, this rule could have strong negative weight if user group has a strong consensus. Rating rules could have also thresholds (minimum of five user ratings etc.). These kind of rules should also affect the CIS selection strategies and ranking. CIs can be contained by many different containers. They can parent many kind of interactions. These have to be dealt with at the view level, the additional interactions are very simple model-wise, they mostly tend to act like additional properties of the CI. The Rules will also analyze the RAR content with mathematical, text matching and other more complex methods. For example, category based navigation would require list of category id's provided (all ancestors) for the unsupervised learning to pick them up properly (in case the business analysts of the client do not trust OBHave's natural capability to find better way to organize the hierarchies of the categories). Some RAR properties should be excluded from the examination range of the rules, since they can create inconsistency and scalability problems if the data changes frequently. CI id's are assumed to never change, but that is a quite safe assumption, since changing resource id's in any systems are huge investments.